Various types of software applications exist, and it is generally considered a favored practice to have some form of documentation that describes the operations that will be performed by the software application. Without such accompanying documentation, one is left to review the underlying code (e.g., the software code that is written in some programming language) to decipher the operations that will be performed during the application's execution. Often, it is difficult and/or inefficient to review the underlying software code, and thus it is often difficult to gain a good understanding of the application's operations from a mere review of the underlying code. In addition, the underlying code may change from time to time (e.g., as new versions of the software application are developed), and so further difficulty and inefficiency arise in attempting to understand the application's operations at a given time. In addition, an understanding of the software application's operations based solely on a review of the underlying software code may only be achieved by persons (e.g., programmers) who are knowledgeable about the programming language in which the application's code is written, and thus many users of the software application and/or other interested parties who are not knowledgeable about the programming language are unable to gain an understanding of the software application's operations in this manner.
Accordingly, documentation is often created for describing the operations of a software application. The documentation may be written in a manner that is more readily understood by persons who are unfamiliar with the programming language in which the software application is coded. In addition, the documentation may provide a more efficient way to gain an understanding of the application's operations than reviewing the application's underlying code, even for persons who are familiar with the programming language in which the underlying code is written. The documentation may describe, for example, what operations the software application may perform in response to certain conditions that it may encounter during its execution.
Conventionally, the documentation for a software application is manually written, e.g., by the software developers and/or by technical writers working under the direction of or in correspondence with the software developers.
One type of software application for which generation and maintenance of corresponding documentation is particularly problematic is that referred to herein as a computer system “management application,” which refers generally to software applications that monitor, control, and/or otherwise manage the operation of computer systems. Computer systems (e.g., information technology systems) are essential to any modern business. These systems have and continue to grow increasingly more complex. For instance, such systems may include distributed centers located anywhere from a few miles apart to those across the continent or in separate countries. Today, personal computers are common and many businesses employ multiple operating systems from various vendors. Often, systems of a company are dispersed in branch offices running critical applications or containing essential data. One exemplary type of computer system management application is that referred to as a Single Point Operations software, which supports centralized control and automated operations of multiple data processing systems.
Tools, such as management applications, are available that integrate operational control of multiple heterogeneous mainframes and distributed systems. These systems include numerous components that need to be managed. Typically, managed objects are used to view, monitor, and manage these components. The managed objects are typically predefined in operational software (e.g., in a management application) for managing the components of the system. For instance, such systems may employ filters that compare managed objects to a property threshold, whereby an alert is raised on a managed object when a property of the object satisfies the threshold.
Many computer system management applications allow users to define rules and corresponding actions that the application is to automatically trigger upon the conditions that it monitors satisfying the defined rules. For instance, a management application may allow a user to define one or more message-matching rules that specify certain messages that the management application receives/detects (e.g., system messages generated by one or more monitored computer systems), and the rules may further specify one or more actions that are to be triggered by the management application upon such a message match.
As an example, Single Point Autoaction Message System (SP-AMS) software is an automation language contained in Operations Sentinel® by Unisys® Corporation. SP-AMS is a utility that allows a user to specify messages to match and actions to automatically perform (e.g., without operator interaction) when a message is received and matched. ClearPath Plus OS 2200 Autoaction Message System (CP-AMS) is also part of Operations Sentinel. SP-AMS automates system operations for MCP and UNIX systems and partitions; and CP-AMS automates system operations for OS 2200 partitions in a ClearPath Plus server.
Operations Sentinel uses a ClearPath (CP)-AMS autoaction database associated with each OS 2200 console and an SP-AMS autoaction database associated with managed UNIX, MCP, and Linux partitions, to identify system messages and automatically execute actions. These actions can include raising alerts that are displayed in the Alerts window of Operations Sentinel Console. In addition to displaying alerts, a user may create rules to activate external paging devices (or other communication/notification devices, such as mobile telephones, etc.) when an alert is raised, acknowledged, or cleared. Actions may also include cross-system commands sent to another managed system.
A primary function of SP-AMS is to parse console messages and respond to problems by taking command actions, raising alerts, and logging exceptions. These actions are specified within a proprietary automation language that is both easy to use and extend.
However, as user-defined automation rules grow, there is a desire to document such automated actions. As discussed above, conventionally developers are required to manually create and update documentation of the automated messages and the actions that result without operator interaction. This becomes particularly problematic in maintaining accurate and up-to-date documentation for user-defined rules that are implemented at any given time, which may vary how a computer system management application manages the managed system(s), such as what events trigger actions, what specific actions are triggered by various events, and so on. In the case of such user-defined rules, the rules that are defined and/or activated may vary from site to site. Thus, while the underlying management application that is installed at various sites may be the same, the rules that users define (e.g., for management of their respective managed systems) may vary, and thus merely documenting the operation of the underlying management application may fail to sufficiently capture/describe the management operations that are active at a given site.